Decentralized and/or hybrid decentralized secure cryptographic key storage method

ABSTRACT

A decentralized and/or hybrid decentralized method for secure cryptography key storage referred to as Mutual Dependency Architecture (MDA) includes the steps of encrypting the cryptographic key using an unlock key; encrypting the unlock key using an encryption tool to create an encrypted seed; and storing the encrypted seed; wherein a user must have access to a first storage area in the device and to a second storage area external to the device in order to access the cryptographic key. In one embodiment, the encryption tool is a store key that is stored in unencrypted form in the first storage area, while the encrypted seed is stored in the second storage area. In another embodiment, the encryption tool is a Hardware Security Module (HSM) having an authentication key that is encrypted using a store key and stored in the second storage area, while the encrypted seed and the store key are stored in unencrypted form in the first storage area. The method can be used to build a fully encrypted and permanently secure network and/or internet of devices and/or things, and to exchange messages between devices on the network.

TECHNICAL FIELD

The present disclosure relates in general to cyber-security and moreparticularly to secure storage of cryptographic keys on decentralizedindividual devices.

BACKGROUND

Cryptographic key storage is a massive problem that has plaguedcryptography since its inception. Cryptographic key exchange problemswere solved with the advent of public cryptography, but securing theprivate or symmetric keys remains a problem. Centralization of keystorage techniques has resulted in a single point of failure whereattackers can focus their efforts. Thus, a need exists for a method ofdecentralized key storage that removes this single point of failure,increasing the security and privacy of the end users who hold thecryptographic keys.

SUMMARY

The present disclosure relates to a hybrid decentralized method forcryptography key storage, which will be referred to hereafter as “mutualdependency architecture.” The method uses a server, database, or device,referred to herein as a central authority, with which users or devicesmust register for authentication. For ease of understanding, the backend of the central authority is extrapolated since there are nearinfinite possible implementations for such a system. The key storage iscompletely on the device end, and sensitive components never touch thecentral authority. The method creates a mutual dependency between thecentral authority and the subject device for the subject device, toenable the subject device to “unlock” its stored cryptographic keys.

In its most basic form, mutual dependency architecture is achieved asfollows. An initial cryptographic key for a device is encrypted byanother cryptographic key, referred to here as the “unlock key.” Theunlock key is encrypted by still another key, referred to as the “storekey,” creating an encrypted seed. The encrypted seed, which is neverstored on the device, is transmitted to the central authority, whichrequires some form of authentication. The store key is then stored inunencrypted form with the encrypted stored keys. This creates ahybrid-decentralized model without a central point of failure. If thecentral authority is breached, the data in the central device isrendered useless without the data stored on the devices.

Alternative schemes can be used for additional security measures, suchas using hardware security modules (HSM) to encrypt the unlock key,which is then stored locally on the device. The password or securityvariables for the HSM are then encrypted with the store key, and theencrypted password or security variables are stored on the centralauthority. This provides an additional layer of protection, since itrequires possession of the physical device, as well as access to thecentral authority, to obtain the stored keys for a device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing a storage scheme according to firstembodiment of the present disclosure.

FIG. 2 is a block diagram showing a basic retrieval scheme according tothe first embodiment of the present disclosure.

FIG. 3 is a block diagram showing a storage scheme according to a secondembodiment of the present disclosure.

FIG. 4 is a block diagram showing an alternative retrieval schemeaccording to a second embodiment of the present disclosure.

FIG. 5 is a block diagram showing a decentralized method of MutualDependency Architecture.

FIG. 6 is a block diagram showing a secure key exchange over a directionconnection.

FIG. 7 is a visual description showing how a permanently secure networkof devices nodes can communicate when not directly connected.

FIG. 8 is a visual description showing how devices can be removed or“blacklisted” from a permanently secure network of devices utilizing amaster device only method.

FIG. 9 is a visual description showing how devices can be removed or“blacklisted” from a permanently secure network of devices utilizing areporting method.

FIG. 10 is a block diagram showing chain deployment.

FIG. 11 is a block diagram showing the concept of ad-hoc trusted thirdparties.

FIG. 12 is a block diagram showing the concept of relay encapsulation.

FIG. 13 is a flow chart illustrating method of securely relaying andpropagating a message through a decentralized permanently secure networkcreated using the cryptographic key storage methods of the presentdisclosure.

DETAILED DESCRIPTION Glossary of Terms

Device—any unit of electronic equipment or hardware equipment havingcomputing ability.

Central authority—a computing device that can be configured as a serverand is capable of authentication and storage.

Cryptographic key—a string of data that is used to lock or unlockcryptographic functions, including authentication, authorization andencryption.

Encrypted stored key—a cryptographic key that has been encrypted andstored on a device.

Unlock key—a cryptographic key used to encrypt an encrypted stored key.

Encrypted seed—an encrypted unlock key.

Store key—a cryptographic key used to encrypt an encrypted seed.

Network—a group of two or more intelligent devices connected by physicalor wireless connections and able to communicate with one another; theterm refers to internets of things or devices, as well as toconventional computer networks.

As required, detailed embodiments of the present invention are disclosedherein; however, it is to be understood that the disclosed embodimentsare merely exemplary of the invention that may be embodied in variousand alternative forms. The figures depicting schemes are just a few ofall the possible implementations. Therefore, specific structural andfunctional details disclosed herein are not to be interpreted aslimiting, but merely as a representative basis for teaching one skilledin the art to variously employ the present invention.

FIG. 1 shows a basic storage scheme 10 according to the presentdisclosure. A cryptographic key or set of keys 12 for a device 14 isencrypted by an unlock key 16 and stored on the device 14. The unlockkey 16 is encrypted by a store key 18, creating an encrypted seed thatis transmitted to a central authority 20 requiring authentication. Theamount of security available is dependent on how the central authority20 is configured and how the authentication is handled. Suitableauthentication methods for the central authority 20 may include, but arenot limited to, basic username and password, OAuth2, biometrics, andvarious combinations thereof. The encrypted stored key or keys 12 may byany type of cryptographic keys, such as private/public cryptographickeys pairs, symmetric ciphers, cryptographic keys, and the like. Theunlock key 16 and the store key 18 utilize symmetric key ciphers, sincesymmetric key cyphers offer the most secure form of encryption and donot require public key functionality.

As shown in FIG. 2, retrieval of a cryptographic key stored by themethod of FIG. 1 requires the device 14 to authenticate with the centralauthority 20 and retrieve the encrypted seed. The store key 18 thendecrypts the encrypted seed to provide the unlock key 16, which in turndecrypts the decrypted stored keys 12. The decrypted stored keys 12 arethen provided in their original form to an end user who requested theunlocking of the keys.

The alternative storage scheme 100 shown in FIG. 3 shows how additionalsecurity components may be added to the basic scheme to increase thelevel of security. The architecture of this scheme 100 is essentiallythe same as the architecture of the scheme 10 shown in FIG. 1, exceptthat the unlock key 116 for the cryptographic key or set of keys 112 fora device 114 is encrypted or “sealed” by a hardware security module(HSM) 115 and stored on the device 114, rather than being encrypted bythe store key 118 and stored on the central authority 120. The HSMpassword or security variables are then encrypted with the store key118, and the encrypted password or security variables are stored oncentral authority 120. The encrypted password or security variables arethen protected behind the authentication configured for the centralauthority 120 and not stored on the device 114. The store key 118 isstill stored unencrypted, or “naked” on the device 114. This alternativestorage scheme 100 has several benefits as it truly binds the encryptedstored keys 112 to the device 114, since the physical hardware securitymodule 115 is needed to decrypt the encrypted stored keys 112. Thus, anattacker must acquire the physical device 114 and access its storage, aswell as breaching the central authority 120 to obtain the stored keysfor device 114. Other alternative schemes utilizing variations of thesame mutual dependency architecture could include, but are not limitedto, other localized security methods such as keychain technology, securedevice storage, and the like.

As shown in FIG. 4, retrieval of a cryptographic key stored by themethod of FIG. 3 requires the device 114 to authenticate with thecentral authority 120, and retrieve the encrypted seed, which in thiscase is the encrypted HSM password or security variables. The store key118 then decrypts the encrypted seed, allowing the HSM 115 to decryptthe encrypted unlock key 118 using the decrypted password or securityvariables. The unlock key 116 then decrypts the encrypted stored keys112, which are in turn provided in their original form to an end userwho requested the unlocking of the keys.

The schemes described, as well as the numerous permutations, can serveas the foundation for creating a fully decentralized and encryptednetwork and/or internet of devices and/or things, since the centralauthority itself serves as a placeholder and can be any type ofcomputing device. Thus, peer-to-peer authentication and key storage ispossible, which will allow for ad-hoc creation of trusted third partiesfor systems that require a third party.

On example of a system using the principles of mutual dependencyarchitecture for peer-to-peer use and implementation is shown in FIG. 5.The system includes a first device 314 having a first HSM 315 and afirst storage module 317, and a second device 319 having a second HSM321 and a second storage module 323. Each HSM contains a public keycryptography system for storing session keys after exchange and use,enabling session key exchanges using the Diffie-Hellman key exchangemethod. After session keys are no longer needed, they are encrypted andstored using the method described above in connection with FIG. 3,except that each device acts as the central authority for the otherdevice.

A method of decentralized peer-to-peer authentication and key storageusing the system of FIG. 5 involves the following steps:

-   -   1) The HSM 315 for the first device 314 supplies its public key        to the first device 314, and the HSM 321 for the second device        319 stores its public key to the second device 319.    -   2) The first device 314 and the second device 319 commence a        secure key exchange.    -   3) The first device 314 encrypts the session key for the second        device 319 using a first unlock key, and the second device        encrypts the session key for the first device 314 using s second        unlock key.    -   4) The first unlock key is encrypted using the HSM 315 for the        first device 314, creating a first encrypted seed, and the        second unlock key is encrypted using the HSM 321 for the second        device 319, creating a second encrypted seed.    -   5) The first encrypted seed is stored on the first device and        the second encrypted seed is stored on the second device.    -   6) The authentication key for the HSM 315 for the first device        314 is encrypted using a first store key, and the authentication        key for the HSM 321 for the second device 321 is encrypted using        a second store key.    -   7) The encrypted authentication key for the first device 314 is        stored on the second device, and the encrypted authentication        key for the second device is stored on the first device.

The method described above is beneficial since the devices 314 and 319can simply exchange the encrypted seeds and reuse the session keys ifcommunications are to be reopened. The encrypted seeds could be alsoexchanged using the Diffie-Hellman method and any risk of a man in themiddle attack on the reopening is nullified, since the exchange data isno longer a key, but just encrypted data that is only relevant to thetalking devices. Furthermore, there can also be additionalauthentication steps, such as returning the signature of random of datathat is sent encrypted with the requesting device's public key to proveownership of the public key pair, and thus the encrypted seed. For theauthentication steps, the devices could also store each other's publickeys after the initial key exchange and use the stored public key asidentifiers.

The decentralized peer-to-peer method described above may also befurther developed to create a permanent secure network that provides asecure environment for the initial key exchanges between all devices inthe network. Such a network may be formed as shown in FIG. 6, by: 1)creating a secure connection between a first device 414 and a seconddevice 419; and 2) initiating a secure key exchange between the twodevices 414, 419 using the Diffie-Hellman method. Once the key exchangeshave occurred, both devices 414, 419 have permanent securecommunications with each other.

A method of securely propagating a message through a network formed bythe method of FIG. 6 is depicted in FIG. 7, where the first device 414and second device 419 have previously been paired using the methoddescribed above, and a third device 425 acts as an intermediary. Sincethe first and second devices 414, 419 are pre-paired, communications canbe started as though it is in the middle of an encrypted session. Themethod of FIG. 7 includes the following steps:

-   -   1) The first device 414 encrypts the message using the session        key it received from the second device 419.    -   2) The first device 414 sends the encrypted message to the third        device 425, which in turn relays the message to the second        device 421.    -   3) The second device 421 re-encrypts the message using the        session key it received from the first device 414.    -   4) The second device 421 sends the re-encrypted message to the        third device 425, which in turn relays the message to the first        device 414.

If a network device is lost or taken by a malicious user, that devicecan simply be excluded or “blacklisted” by the network, and the abilityto view its previous conversations will be impossible unless the useralso acquires another device from the network. The blacklisting processcould be achieved by issuing a command that a public key is invalidthrough a master device, which will be relayed to all devices throughoutthe network. The basic schema of this blacklisting or invalidationmethod is depicted in FIG. 8, which shows a network 500 including amaster device 502 and three subsidiary devices. The three subsidiarydevices include a first subsidiary device 504 that is directly connectedto the master device 502, a second subsidiary device 506 that cancommunicate with the first subsidiary device 504, and a third subsidiarydevice 508 that has been lost or stolen. Each of the subsidiary devices504, 506, and 508 has its own public key, and the master device 502 iscapable of invalidating each of these public keys. When the masterdevice 502 is notified that the third subsidiary 508 device has beenlost or stolen, it invalidates the public key for the third subsidiarydevice 508 and notifies the first subsidiary device 504 that the thirdsubsidiary device is no longer a valid network device. The firstsubsidiary device 504 then relays this information to the secondsubsidiary device 506.

A decentralized approach could also be taken where the submittal ofmultiple “reports” by trusted network devices that a network device iscompromised will result in the invalidation of the reported device'spublic key. This method is depicted in FIG. 9, which shows the samenetwork 500 as FIG. 8, but where the second auxiliary device 506, ratherthan the third auxiliary device 508, has been lost, stolen, or capturedby malicious users. In this scenario, the first auxiliary device 504 andthe third auxiliary device 508 report the loss of the second auxiliarydevice 506 to the master device 502. When the master device 502 receivesa threshold number or reports that the third auxiliary device 508 hasbeen lost, it attempts to render the third auxiliary device 508 byissues it “delete keys” command. The master device 502 then sendsinvalidation reports to all other devices in the network, using themethod described in relation to FIG. 8.

In a hybrid approach, the validity of a reported device's public key canbe suspended until it is either permanently revoked by the master device502 or overridden as valid. In addition, a system could be implementedwherein the master device is identified as compromised if it issuescommands on devices that have not been reported by other devices (ie. itreports a device as stolen when no other device has reported that devicestolen. This kind of system would be excellent for communicatingtime-sensitive data where past transmissions have an expiration of theirusefulness, since there is vulnerability that previous communicationscan be seen if the two devices are captured. Granted that suchvulnerabilities maybe mitigated by device security mechanisms such asand not limited to biometrics, dual factor authentication, etc., whichmay prevent the captured devices from being used to begin with.

In some situations, it may be necessary to replace a device in anetwork, or to do a rolling deployment of a network when a newgeneration of devices has been introduced. In these situations, it isdesirable to create an ad-hoc trusted third party.

One method of deploying a decentralized, permanently secure ad-hocnetwork is shown in FIG. 10. When a first generation 602 of devices isreleased, all the devices in that generation exchange session keys usinga secure pairing method. A first subset of the first generation isdeployed to create a first network 604 consisting entirely of firstgeneration devices, while a second subset 606 of the first generation isheld in reserve. When a second generation 608 is released, each devicein the second generation 608 exchanges exchange session keys with atleast one other device in the second generation 608 and at least onedevice from the second subset 606 of the first generation using a securepairing method. A first subset of the second generation 608 is thendeployed with the second subset 606 of first generation devices tocreate an ad-hoc second network 610 consisting of both first and secondgeneration devices. A second subset 612 of the second generation is heldin reserve for pairing with a future third generation.

FIG. 11 shows a method for preventing “man in the middle” attacks on anad hoc network created by the method of FIG. 10. In this scenario, whena second generation device 702 encounters a first generation device 704it has not exchanged keys with, each device will search for third device706 that has already exchanged session keys with both devices. Once boththe second generation device 702 and the first generation device 704determine that the third device 706 has previously exchanged keys withboth, they designate the third device 06 as a trusted third party. Thefirst and second generation devices 702, 704 then commence a secure keyexchange, using the third device 706 as a communication channel. Oncethe keys are stored and the exchange is completed, second generationdevice 702 and first generation device 704 can both act as trusted thirdparty for other devices. This method will be referred to hereafter as“chained deployment.”

Communication among the devices of FIGS. 10 and 11 is kept secure usinga method, referred to here as “relay encapsulation”, which is depictedin FIG. 12. For the sake of simplicity, the method is illustrated herein relation to a network comprising three devices: a first device 802, asecond device 804, and a third device 806, where the first device 802 isdirectly connected to, and has previously swapped session keys with, thesecond device 804 and the second device 804 is directly connected to,and has previously exchanged session keys with, the third device 806,and where the third device 806 is distant from, or not directlyconnected to, the first device 802.

The method for propagating an original message M_(o) through thethree-device network 800 of FIG. 12 is as follows:

-   -   1) The first device 802 and the third device 806 exchange        session keys.    -   2) The first device 802 computes a secure hash of the original        message M_(o) and appends it to the secure hash of the original        message M_(O) to create an augmented message M_(1A) having a        data section and a hash section.    -   3) The augmented message M_(1A) is encrypted in the first device        802 using the session keys exchanged between the first device        802 and the third device 806 (S₁₍₃₎) to create an encrypted        augmented message M_(1B).    -   4) The encrypted augmented message M_(1B) is encrypted using the        session keys exchanged between the first device 802 and the        second device 804 (S₁₍₂₎) to create a double-encrypted augmented        message M_(1C).    -   5) The double-encrypted augmented message M_(1C) is transmitted        to the second device 804.    -   6) The second device 804 decrypts the double-encrypted augmented        message M_(1C) using the session keys exchanged between the        first device 802 and the second device (S₁₍₂₎) to create a        single-encrypted augmented message M_(2B).    -   7) The second device 804 encrypts the single-encrypted augmented        message M_(2B) using the session keys exchanged between the        second device 804 and the third device 806 (S₂₍₃₎).    -   8) The second device 804 transmits the single-encrypted        augmented message M_(2B) to the third device 806.    -   9) The third device decrypts the single-encrypted augmented        message M_(2B) twice to receive the plain text original message        M_(o) and verifies its validity by calculating and comparing the        decrypted hash and the computed hash.

The method of FIG. 12 can readily be extrapolated to a longer chain ofdevices D₁-D_(n), wherein each device D_(x) has previously exchangedsession keys with a subsequent device D_(x+1) so that the first deviceD₁ contains the session key S₁₍₂₎ for the second device D₂, every deviceD_(x) between the first device D₁ and the last device D_(n) contains thesession key S_(x(x−1)) for a previous device D_(x−1) and the session keyS_(x(x+1)) for a subsequent device D_(x+1); and the end device D_(n)contains the session key S_(n(n−1)) for the penultimate device D_(n−1).The method for propagating messages through the longer chain of devicesis the same as for the three-device chain, except that a verificationstep is added at each device to verify whether the endpoint of thetransmission has been reached, as shown in the flow chart of FIG. 13.The verification step consists of: attempting to decrypt thesingle-encrypted augmented message with all stored session keys tocreate a set of possible messages; computing a hash of the data sectionof each of the messages; and comparing the hash on the data section ofeach message with its hash section. If the hash on the data section ofany message is the same as the hash of that message, the endpoint hasbeen reached. If not, the single-encrypted augmented message must bere-encrypted and transmitted to the next device, where the entireprocess is repeated.

In some cases, the initial encapsulation step of this method can beskipped, since the messages can be viewed by the relaying deviceswithout risking a security breach.

There are many ways the concept of chained deployment described inconnection with FIG. 11 can be deployed. An algorithm or a neural netcould determine the ideal exchange pairing per deployment of devices andapply this information to future deployments. For example, an algorithmor neural net may find that the devices that have been held in reservefrom the first generation of devices should be spread out over the nextfive subsequent generations, since as each deployment of devices candiffer. This optimization and chain deployment shows that a permanentlysecure network utilizing mutual dependency architecture need not bestatic and can adapt to new devices, and lost devices as well, as it iscontinuously expanded. Mutual dependency architecture allows upgrades tociphers or other components of the devices to be performed on a rollingbasis, since the cryptographic keys stored do not need to be of a singlecipher.

An alternative method of deployment, referred to here as “proximitypropagation deployment, operates on the assumption that all directconnections are “secure” and performs the initial key exchanges usingthe method described in connection FIG. 6. Once all the localized pairshave exchanged their session keys, any device within the subnet can betied to a secure chain of ad-hoc trusted third parties using the methoddescribed in connection with FIG. 11. Furthermore, when combined withchained deployment of networking gear, such as switches and routers,propagation can continue to pair routers and switches as needed tocreate a network with the capabilities needed. Alternatively, thenetworking gear can simply propagate with its nearest connection. Oncepropagation is finished, two devices on separate subnets can now beginkey exchanges through a chain of ad-hoc trusted third parties. Apermanent secure session can be established, or rather for efficiency,the session key can be discarded when its use is no longer needed. Apermanent secure session does not need a chain of ad-hoc trusted thirdparties and can go the most direct route as man in the middle attacksare completely negated.

If a node of the network is malicious or captured, the chain of ad-hoctrusted third parties may become vulnerable to a man-in-the-middleattack. This can be mitigated by chained deployment of “master” servers,which can function as domain name servers. Those master servers couldalso utilize a form of block chain to create a master ledger of devicesand their corresponding identities. Users will register their server'sembedded public keys with the master servers so all connecting deviceswill know what public key to expect from the server response.

What is claimed is:
 1. A method for storing a cryptographic key for adevice in a network, comprising: encrypting the cryptographic key usingan unlock key; encrypting the unlock key using an encryption tool tocreate an encrypted seed; and storing the encrypted seed; wherein a usermust have access to a first storage area in the device and to a secondstorage area external to the device in order to access the cryptographickey.
 2. The method of claim 1, wherein the secure location is part of acentral authority, wherein the central authority is a server, database,or device requiring user registration and authentication.
 3. The methodof claim 1, wherein: the encryption tool comprises a store key; theencrypted seed is stored in the second storage area; and the store keyis stored in unencrypted form in the first storage area.
 4. The methodof claim 1, wherein the encryption tool comprises a hardware securitymodule having an authentication key.
 5. The method of claim 4, furthercomprising: storing the encrypted seed in the first storage area;encrypting the authentication key using a store key; storing theencrypted authentication key in the second storage area; and storing thestore key in unencrypted form in the first storage area.
 6. A method ofdecentralized peer-to-peer authentication and key storage, comprising:storing a first cryptographic key for a first device D₁ using the methodof claim 1, wherein the second location is a second device; and storinga second cryptographic key for the second device D₂ using the method ofclaim 1, wherein the second location is the first device; and whereinthe first and second devices require authentication.
 7. A method forcreating a decentralized permanently secure ad-hoc network comprising:associating a first device D₁ with a first hardware security module anda second device D₂ with a second hardware security module, wherein boththe first device D₁ and the second device D₂ require authentication;using the first hardware security module to provide a first securepublic key pair for the first device D₁; using the second hardwaresecurity module to provide a second secure public key pair for thesecond device D₂; using a random seed from the first device D₁ encryptedwith the second device's secure public key pair, sent to the seconddevice D₂, decrypted by the second device D₂, re-encrypted with thefirst device's secure public key pair, returned to the first device D₁,and decrypted and verified by the first device D₁ as proof of ownershipand authentication of the second device's secure key pair, using arandom seed from the second device D₂ encrypted with the first device'ssecure public key pair, sent to first device D₁, decrypted by the firstdevice, re-encrypted with the second device's secure public key pair,returned to the second device D₂, and decrypted and verified by thesecond device D₁ as proof of ownership and authentication of the firstdevice's secure key pair; using the first and second secure key pairs tosecurely exchange permanent or temporary session keys between the firstand second devices; storing the session key S₁ for the first device D₁in the second device D₂ using the method of claim 5; storing the sessionkey S₂ for the second device D₂ in the first device D₁ using the methodof claim
 5. 8. A decentralized permanently secure ad-hoc network createdusing the method of claim 7, comprising an uninterrupted chain ofdevices D₁-D_(n), wherein each device D_(x) has previously exchangedsession keys with a subsequent device D_(x+1) so that: the first deviceD₁ contains the session key S₁₍₂₎ for the second device D₂; every deviceD_(x) between the first device D₁ and the last device D_(n) contains thesession key S_(x(x−1)) for a previous device D_(x−1) and the session keyS_(x(x+1)) for a subsequent device D_(x+1); and the end device D_(n)contains the session key S_(n(n−1)) for the penultimate device D_(n−1).9. A method of securely relaying and propagating an original messageM_(O), through the network of claim 8, comprising: a) performing asecure key exchange between the first device D₁ and the end device D_(n)over the uninterrupted chain of devices; b) computing a secure hash ofthe original message M_(O) c) appending the secure hash to the end ofthe original message M_(O) to create an augmented message M_(1A) havinga data section and a hash section d) encrypting the augmented messageM_(1A) in the first device D₁ using the exchanged session key S_(1(n))to create an encrypted augmented message M_(1B); e) encrypting theencrypted augmented message M_(1B) using the session key S₁₍₂₎ to createa double-encrypted augmented message M_(1C); f) transmitting thedouble-encrypted augmented message M_(1C) to the second device D₂; g)decrypting the double-encrypted augmented message M_(1C) with thesession key S₁₍₂₎ to create a single-encrypted augmented message M_(2B);h) attempting to decrypt the single-encrypted augmented message M_(2B)with all stored session keys to create possible messages M_(1A(d)), eachof the possible messages having a data section and a hash section; andi) computing a hash on the data section of each M_(1A(d)) message andcomparing it to the hash section of each M_(1A(d)) message to verify ifthe endpoint is reached; and j) if not at D_(n), i) re-encrypting thesingle-encrypted augmented message M_(2B) using the session keys S₂₍₃₎,to create M_(3C), ii) transmitting M_(3C) to the third device D₃, iii)decrypting the double-encrypted augmented message M_(3C) with thesession key S₂₍₃₎ to create a single-encrypted augmented message M3Bhaving a data section and a hash section, iv) attempting to decrypt thesingle-encrypted augmented message M_(3B) with all stored session keysto create possible messages M_(1A(d)), v) computing a hash on the datasection of M_(1A(d)) messages, and vi) comparing the hash on the datasection of M_(1A(d)) to the hash section of the M_(1A(d)) messages toverify if the endpoint is reached; and vii) if not at endpoint oftransmission, viii) create M_(xC) from M_(3B) and transmitting M_(xC) tosubsequent devices D_(x), and ix) repeating steps j) i through j) viiiuntil device D_(n) is reached.
 10. The method of claim 9, wherein thechain of devices is created through IP routing and all non-paired nodeson routing table perform key exchanges.
 11. The method of claim 9,wherein: each device has a public key and a private key; the public keysfor the first device D₁ and the last device Dn are appended to theoriginal message to determine place of origin and end point; and onlyattempting to decrypt the single encrypted message once the messagereaches the endpoint with initially exchange session keys.
 12. Themethod of claim 9, wherein the chain of devices is assumed trusted toform an ad-hoc chain of trusted third parties.
 13. A method forinvalidating and/or removing devices/things on a decentralizedpermanently secure ad-hoc network comprising: associating anuninterrupted chain of devices with a master device, wherein each devicehas its own public key and the master device can invalidate the publickey for each device; and using the method of claim 9 to send aninvalidity message to the master device if any device in the networkdetermines that another device in the network is malicious, promptingthe master device to invalidate the public key for the malicious device.14. A method for deploying a decentralized, permanently secure ad-hocnetwork, comprising: acquiring a first generation of devices from aproduct line having a lifespan; using a secure pairing method to paireach device in the first generation of devices with at least one otherdevice in the first generation of devices to allow secure communicationsamong the entire first generation of devices; deploying a subset of thedevices in the first generation of devices, while leaving behind aremainder of the first generation of devices; acquiring a secondgeneration of devices from the same product line; using the securepairing method to pair each device in the second generation of deviceswith at least one other device in the second generation of devices andat least one device in the remainder of the first generation of devices;deploying a subset of the devices in the second generation of devices,while leaving behind a remainder of the second generation of devices;and repeating for the lifespan of the product line.
 15. The method ofclaim 14, wherein using a secure pairing method to pair each device inthe first generation of devices with at least one other device in thefirst generation of devices comprises using the secure pairing method topair all the devices in the first generation of devices with oneanother.
 16. The method of claim 14, wherein using a secure pairingmethod to pair each device in the first generation of devices with atleast one other device in the first generation of devices comprisesusing the secure pairing method to strategically pair each device withat least one other device.
 17. The method of claim 14, wherein eachdevice requires authentication.
 18. The method of claim 17, whereinusing a secure pairing method to pair each device in the firstgeneration of devices with at least one other device in the firstgeneration of devices comprises: encrypting a first cryptographic keyfor a first device using a first unlock key; encrypting a secondcryptographic key for a second device using a second unlock key;encrypting the first unlock key using a first store key to create afirst encrypted seed; encrypting the second unlock key using a secondstore key to create a second encrypted seed; storing the first encryptedseed on a second device; storing the second encrypted seed in the firstdevice; storing the first store key in unencrypted form on the firstdevice; and storing the second store key in unencrypted form on thesecond device.
 19. The method of claim 17, wherein using a securepairing method to pair each device in the first generation of deviceswith at least one other device in the first generation of devicescomprises: associating a first device with a first hardware securitymodule having a first authentication key; associating a second devicewith a second hardware security module having a second authenticationkey; encrypting a first cryptographic key for the first device using afirst unlock key; encrypting a second cryptographic key for the seconddevice using a second unlock key; encrypt the first unlock key using thefirst hardware security module; encrypt the second unlock key using thesecond hardware security module; storing the encrypted first unlock keyon the first device; storing the encrypted second unlock key on thesecond device; encrypting the first authentication key using a firststore key; encrypting the second authentication key using a second storekey; storing the encrypted first authentication key in the seconddevice; storing the encrypted second authentication key in the firstdevice; storing the first store key in unencrypted form on the firstdevice; and storing the second store key in unencrypted form on thesecond device.
 20. A method for deploying a decentralized ad-hocnetwork, comprising: providing a plurality of devices including at leastone localized pair of devices consisting of a first device D₁ that hasbeen directly connected to a second device D₂ using a secure keyexchange, and at least one distant device Dy; and pairing each device ineach localized pair of devices with a distant device Dy using the methodof claim 7 to create an uninterrupted chain of devices D₁-D_(n), whereineach device D_(x) has previously exchanged session keys with asubsequent device D_(x+1) so that: the first device D₁ contains thesession key S₂ for the second device D₂; every device D_(x) between thefirst device D₁ and the last device D_(n) contains the session keyS_(x−1) for a previous device D_(x−1) and the session key S_(x+1) for asubsequent device D_(x+1); and the last device D_(n) contains thesession key for the next-to-last device D_(n−1).
 21. A method ofrelaying and propagating a message through the decentralized ad-hocnetwork deployed in claim 20, comprising a) performing a secure keyexchange between the first device D₁ and the end device D_(n) over theuninterrupted chain of devices; b) computing a secure hash of theoriginal message M_(O) c) appending the secure hash to the end of theoriginal message M_(O) to create an augmented message M_(1A) having adata section and a hash section d) encrypting the augmented messageM_(1A) in the first device D₁ using the exchanged session key S_(1(n)),to create an encrypted augmented message M_(1B); e) encrypting theencrypted augmented message M_(1B) using the session key S₁₍₂₎ to createa double-encrypted augmented message M_(1C); f) transmitting thedouble-encrypted augmented message M_(1C) to the second device D₂; g)decrypting the double-encrypted augmented message M_(1C) with thesession key S₁₍₂₎ to create a single-encrypted augmented message M_(2B);h) attempting to decrypt the single-encrypted augmented message M_(2B)with all stored session keys to crate possible messages M_(1A(d)), eachof the possible messages having a data section and a hash section; andi) computing a hash on the data section of each M_(1A(d)) message andcomparing it to the hash section of each M_(1A(d)) message to verify ifthe endpoint is reached; and if not at D_(n), j) re-encrypting thesingle-encrypted augmented message M_(2B) using the session keys S₂₍₃₎to create M_(3C), ii) transmitting M_(3C) to the third device D, iii)decrypting the double-encrypted augmented message M_(3C) with thesession key S₂₍₃₎ to create a single-encrypted augmented message M3Bhaving a data section and a hash section, iv) attempting to decrypt thesingle-encrypted augmented message M_(3B) with all stored session keysto create possible messages M_(1A(d)), v) computing a hash on the datasection of M_(1A(d)) messages, and vi) computing the hash on the datasection of M_(1A(d)) messages and comparing it to the hash section ofthe M_(1A(d)) messages to verify if the endpoint is reached; and if notat endpoint of transmission, vii) create M_(xC) from M_(3B) andtransmitting M_(xC) to subsequent devices D_(x), and viii) repeatingsteps j) i-vii until device D_(n) is reached.
 22. The method of claim21, wherein the chain of devices is created through IP routing and allnon-paired nodes on routing table perform key exchanges.
 23. The methodof claim 21, wherein: each device has a public key and a private key;the public keys for the first device D₁ and the last device Dn areappended to the original message to determine place of origin and endpoint; and only attempting to decrypt the single encrypted message oncethe message reaches the endpoint with initially exchange session keys.